Психиатрия и системный дизайн

Заметок не было довольно долго — у нас с женой родился ребенок и у меня случилось увлекательное погружение в мир грязных ползунков и детского кала 😀 💩 Теперь же процессы управления моей жизнью как-то нормализовались и появилось время что-то написать.

Обсудим сегодня важный вопрос — выбор структуры команды тестирования (они же QA инженеры).

Есть три способа расположить QA внутри вашей компании:

1️⃣ Вариант 1. Отдельные команды разработки и отдельная от них команда тестирования. Разработчики закончили работу над своим кодом, отдали фичу на проверку в другую команду. и пусть QA уже там с ней возятся. В этом случае, как правило, QA отбирает в релизы фичи, прошедшие тесты и формирует релиз-план новой версии программы.
2️⃣ Вариант 2. Специалисты тестирования являются частью продуктовой команды. Инженеры закончили разработку, передали фичи в тестирования специалистам QA внутри своей команды. После тестирования сама команда принимает решение о релизе и выпускает свой код в продакшн.
3️⃣ Вариант 3. QA нет, фичи тестируют сами же разработчики внутри команды. При описании этого способа часто звучат слова “quality assurance vs quality assistance” — вертикальные команды и сами инженеры несут непосредственную и полную ответственность за то, что они сделали.

Мое оценочное суждение — “Вариант 3” это неэффективная и опасная методология, которая приобрела популярность у некоторых менеджеров только из-за своей типа поэтичности (”мы несем ответственность за то, что делаем, у вас должен был ОВНЕРШИП 🙀”). Причин этой опасности и неэффективности две.

Причина первая — устройство нашего человеческого мозга 🧠 Если ты что-то строишь, то психологически не можешь взять результаты своего труда и как следует несколько раз ударить их с размаху об стену, чтобы посмотреть, как твое творение выдержит такой стресс-тест. А еще есть когнитивная ошибка искажения — мы все склонны искать подтверждения того, что правильно сделали свою работу, тогда как QA должны стараться доказать, что в работе есть ошибки. Короче, мозг не позволяет нам тестировать свой код на полную и хорошо.

Причина вторая — финансы 💸 Разработчики и QA специалисты обладают разными квалификациями. Хорошие разработчики организуют паттерны, базы данных, шины и файловые хранилища. Хорошие QA делают фаззинг, манки тестинг, нагрузочное тестирование, автоматические и ручные проверки. Просить людей из первой группы хорошо делать работу людей второй группы — экономически бессмысленно.

Вариант 3️⃣ — дорогой, полный когнитивных искажений и эмоциональных проблем способ выпускать софт, которые потенциально содержит баги.

Поэтому при организации структуры QA отдела мы всегда выбираем между “отдельная команда” и “интегрированные QA специалисты внутри других команд” (кстати, можно выбрать сразу два варианта, когда часть тестов делается внутри продуктовой команды и часть — снаружи).

Чтобы выбрать структуру оптимально, нужно ответить на один вопрос: “Должна ли наша компания релизить фичи централизованно и одномоментно? Или можно выпускать их каждый день порциями по чуть-чуть?”. Если должна — то нужно построить отдельную QA команду, если нет — то оптимальным решением будет внедрять QA в продуктовые команды.

На сегодня все, обнял-приподнял, всех с наступающими праздниками 🎉

www.tg-me.com/fr/Психиатрия и системный дизайн/com.psychiatry_and_system_design/11

272 viewsDec 21, 2022 at 10:30

Заметок не было довольно долго — у нас с женой родился ребенок и у меня случилось увлекательное погружение в мир грязных ползунков и детского кала 😀 💩 Теперь же процессы управления моей жизнью как-то нормализовались и появилось время что-то написать.

Обсудим сегодня важный вопрос — выбор структуры команды тестирования (они же QA инженеры).

Есть три способа расположить QA внутри вашей компании:

1️⃣ Вариант 1. Отдельные команды разработки и отдельная от них команда тестирования. Разработчики закончили работу над своим кодом, отдали фичу на проверку в другую команду. и пусть QA уже там с ней возятся. В этом случае, как правило, QA отбирает в релизы фичи, прошедшие тесты и формирует релиз-план новой версии программы.
2️⃣ Вариант 2. Специалисты тестирования являются частью продуктовой команды. Инженеры закончили разработку, передали фичи в тестирования специалистам QA внутри своей команды. После тестирования сама команда принимает решение о релизе и выпускает свой код в продакшн.
3️⃣ Вариант 3. QA нет, фичи тестируют сами же разработчики внутри команды. При описании этого способа часто звучат слова “quality assurance vs quality assistance” — вертикальные команды и сами инженеры несут непосредственную и полную ответственность за то, что они сделали.

Мое оценочное суждение — “Вариант 3” это неэффективная и опасная методология, которая приобрела популярность у некоторых менеджеров только из-за своей типа поэтичности (”мы несем ответственность за то, что делаем, у вас должен был ОВНЕРШИП 🙀”). Причин этой опасности и неэффективности две.

Причина первая — устройство нашего человеческого мозга 🧠 Если ты что-то строишь, то психологически не можешь взять результаты своего труда и как следует несколько раз ударить их с размаху об стену, чтобы посмотреть, как твое творение выдержит такой стресс-тест. А еще есть когнитивная ошибка искажения — мы все склонны искать подтверждения того, что правильно сделали свою работу, тогда как QA должны стараться доказать, что в работе есть ошибки. Короче, мозг не позволяет нам тестировать свой код на полную и хорошо.

Причина вторая — финансы 💸 Разработчики и QA специалисты обладают разными квалификациями. Хорошие разработчики организуют паттерны, базы данных, шины и файловые хранилища. Хорошие QA делают фаззинг, манки тестинг, нагрузочное тестирование, автоматические и ручные проверки. Просить людей из первой группы хорошо делать работу людей второй группы — экономически бессмысленно.

Вариант 3️⃣ — дорогой, полный когнитивных искажений и эмоциональных проблем способ выпускать софт, которые потенциально содержит баги.

Поэтому при организации структуры QA отдела мы всегда выбираем между “отдельная команда” и “интегрированные QA специалисты внутри других команд” (кстати, можно выбрать сразу два варианта, когда часть тестов делается внутри продуктовой команды и часть — снаружи).

Чтобы выбрать структуру оптимально, нужно ответить на один вопрос: “Должна ли наша компания релизить фичи централизованно и одномоментно? Или можно выпускать их каждый день порциями по чуть-чуть?”. Если должна — то нужно построить отдельную QA команду, если нет — то оптимальным решением будет внедрять QA в продуктовые команды.

На сегодня все, обнял-приподнял, всех с наступающими праздниками 🎉

BY Психиатрия и системный дизайн